Skip to content

Conversation

@Architector4
Copy link
Contributor

unordered_set::erase invalidates the pointer that was erased.

https://en.cppreference.com/w/cpp/container/unordered_set/erase.html

References and iterators to the erased elements are invalidated. Other iterators and references are not invalidated.

I also tested with a fresh C++ code file with -fsanitize-address and, indeed, the pattern of code of using an iterator variable to erase and then accessing through it reliably explodes.


What prompted this is that I have just had a completely random segfault crash originating from SDL_Scancode () (????????) while playing the game. Here's the gdb backtrace (yes i play this game in debug build in gdb at this point lmao):

(gdb) bt
#0 0x0000555556b39558 in typeinfo name for SDL_Scancode ()
#1 0x0000555555ae47aa in RTE::MovableMan::Update (this=0x555557453f50) at ../Source/Managers/MovableMan.cpp:1618
#2 0x000055555567597c in RunGameLoop () at ../SourceMain.cpp:354
#3 0x000055555567658a in main (argc=1 argv=0x7fffffffdc88) at ../Source/Main.cpp:468

The last sensible location in that backtrace is right after the erase.

Nothing seems to be broken with this applied.


There are comments and code around these spots that this commit touches that are apparently to work around the same issue I experienced. They're probably redundant/unneeded any more lol

`unordered_set::erase` invalidates the pointer that was erased.

https://en.cppreference.com/w/cpp/container/unordered_set/erase.html

> References and iterators to the erased elements are invalidated. Other iterators and references are not invalidated.

I also tested with a fresh C++ code file with `-fsanitize-address` and, indeed, the pattern of code of using an iterator variable to erase and then accessing through it reliably explodes.

---

What prompted this is that I have just had a completely random segfault crash originating from `SDL_Scancode ()` (????????) while playing the game. Here's the gdb backtrace (yes i play this game in debug build in gdb at this point lmao):

```
(gdb) bt
#0 0x0000555556b39558 in typeinfo name for SDL_Scancode ()
cortex-command-community#1 0x0000555555ae47aa in RTE::MovableMan::Update (this=0x555557453f50) at ../Source/Managers/MovableMan.cpp:1618
cortex-command-community#2 0x000055555567597c in RunGameLoop () at ../SourceMain.cpp:354
cortex-command-community#3 0x000055555567658a in main (argc=1 argv=0x7fffffffdc88) at ../Source/Main.cpp:468
```

The last sensible location in that backtrace is right after the erase.

Nothing seems to be broken with this applied.

---

There are comments and code around these spots that this commit touches that are apparently to work around the same issue I experienced. They're probably redundant/unneeded any more lol
@Causeless
Copy link
Contributor

Feels dumb I didn't catch this. Nice one!

@Causeless Causeless merged commit 066841d into cortex-command-community:development Nov 3, 2025
0 of 4 checks passed
@Architector4 Architector4 deleted the patch-2 branch November 14, 2025 12:06
@numanair
Copy link

numanair commented Dec 3, 2025

I just had a crash:

EXCEPTION_ACCESS_VIOLATION at address 0x7FF68FC2DC44.

Unable to get symbol name at address.
Symbol Handler failed to initialize because

The parameter is incorrect.

Stack trace (most recent call last):
#4    Object "", at 00007FF8979AE8D7, in BaseThreadInitThunk
#3    Source "D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl", line 288, in __scrt_common_main_seh
#2    Source "D:\a\Cortex-Command-Community-Project\Cortex-Command-Community-Project\Source\Main.cpp", line 471, in main
#1    Source "D:\a\Cortex-Command-Community-Project\Cortex-Command-Community-Project\Source\Main.cpp", line 355, in RunGameLoop
#0    Source "D:\a\Cortex-Command-Community-Project\Cortex-Command-Community-Project\Source\Managers\MovableMan.cpp", line 1617, in RTE::MovableMan::Update

Is it related to this change?

@Architector4
Copy link
Contributor Author

Is it related to this change?

MovableMan.cpp", line 1617

Unlikely I think. Line 1617 is (*iIt)->DestroyScriptState(); and the one immediately after is delete (*iIt);, and both shouldn't cause crashing unless state was corrupted beforehand.

The game does keep having random rare memory corruption crashes in most random of places for me, and when I ran the game with gcc's undefined behavior analyzer, it kept spewing quite a bunch of various runtime errors related to things being wrong classes or something... I think the codebase is just kind of a swiss cheese at the moment with undefined behavior, and that inevitably bites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants